Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/app/dashboard/planos/planos-client.test.tsx` around lines 209 - 232, The
edit-action tests are querying the wrong text, so they may miss the actual
control rendered by PlanosClient. Update the selectors in the tests to target
the real edit label used by the UI, using the “Editar” text or a role/name query
instead of “P”. Keep the assertions around opening the form and calling
updatePlanoAction the same, just fix the element lookup in the PlanosClient test
cases.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/app/login/page.test.tsx` around lines 87 - 90, The login page test setup
is leaking the previous `mockGetSession` implementation because
`vi.clearAllMocks()` only clears calls, not behavior. Stub `mockGetSession`
explicitly in this case and, in the submit flow around `resolveAuth({ error:
null })`, await the async handler to settle before the test ends so the
`/dashboard` navigation completes without racing teardown.

Check if this issue is valid — if so, understand the root cause and fix it. At src/app/dashboard/planos/planos-client.test.tsx, line 229:

<comment>The `updatePlanoAction` edit-submit test passes with only a bare `toHaveBeenCalled()` — it doesn't assert which arguments were passed. The existing `createPlanoAction` test in this same file properly verifies both the action arguments and `router.refresh()`. Without these assertions, this test would continue passing if the wrong plano ID were sent or if the success callback stopped refreshing the page, masking a real regression.</comment>

<file context>
@@ -206,6 +206,62 @@ describe('PlanosClient', () => {
+    fireEvent.click(screen.getByTestId('submit-plano'));
+
+    await waitFor(() => {
+      expect(updatePlanoAction).toHaveBeenCalled();
+      expect(mockNotify.success).toHaveBeenCalledWith('Plano atualizado!', expect.any(String));
+    });
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At src/app/login/page.test.tsx, line 147:

<comment>The `window.location` restoration via `Object.defineProperty` at the end of the success test is not resilient to assertion failures. If the `waitFor` times out (e.g., in slow CI or if mock behavior changes), the test throws before reaching the restoration line, leaving `window.location` as a plain object for all subsequent tests in this file. Consider wrapping the assertion and restoration in a `try/finally` block or moving the restoration to an `afterEach` hook.</comment>

<file context>
@@ -98,4 +114,79 @@ describe('LoginPage', () => {
+    });
+
+    const originalLocation = window.location;
+    Object.defineProperty(window, 'location', {
+      value: { ...originalLocation, href: '' },
+      writable: true,
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At src/app/login/page.test.tsx, line 171:

<comment>'Autenticando...' test relies on `mockGetSession` implementation leaking from the previous test — `vi.clearAllMocks()` resets call history but not mock implementations, so the session polling loop after sign-in silently resolves using the neighbor test's configuration. Add `mockGetSession.mockResolvedValue(...)` or `mockResolvedValueOnce(...)` inside this test to make it self-contained.</comment>

<file context>
@@ -98,4 +114,79 @@ describe('LoginPage', () => {
+    });
+  });
+
+  it('shows "Autenticando..." while submitting', async () => {
+    let resolveAuth!: (v: { error: null | Error }) => void;
+    mockSignInWithPassword.mockImplementation(
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At src/app/dashboard/planos/planos-client.test.tsx, line 211:

<comment>`screen.getAllByText('P')` queries for elements containing the text "P" — this likely matches avatar fallback initials rather than the "Editar" button the test title describes. If the component renders edit buttons with a pencil icon or "Editar" label, this query will either click the wrong element or break if the avatar text changes. Consider using `screen.getAllByText('Editar')` or a role-based query (`getByRole('button', { name: /editar/i })`) to target the intended edit action.</comment>

<file context>
@@ -206,6 +206,62 @@ describe('PlanosClient', () => {
 
+  it('opens form in edit mode when "Editar" is clicked', () => {
+    render(<PlanosClient initialPlanos={mockPlanos} />);
+    const editButtons = screen.getAllByText('P');
+    fireEvent.click(editButtons[0]);
+    expect(screen.getByTestId('form-plano')).toBeTruthy();
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At src/app/dashboard/planos/planos-client.test.tsx, line 247:

<comment>The new test 'displays "mês" badge when duration is exactly 30 days' duplicates coverage already provided by the existing 'displays formatted duration badges' test. Since mockPlanos already includes a plano with duracaoDias: 30 (plano-1), the existing test already verifies that a 30-day duration renders the 'mês' badge. This test adds no new behavioral coverage. Consider removing it to keep the test suite focused, or if you want explicit documentation of the 30-day → 'mês' mapping, consider merging it into a parameterized test alongside the other duration cases.</comment>

<file context>
@@ -206,6 +206,62 @@ describe('PlanosClient', () => {
+    });
+  });
+
+  it('displays "mês" badge when duration is exactly 30 days', () => {
+    const customPlanos: Plano[] = [{ id: 'p2', nome: 'Mensal', preco: 100, duracaoDias: 30 }];
+    render(<PlanosClient initialPlanos={customPlanos} />);
</file context>